[00:00.640 --> 00:06.940]  Hi, welcome to our talk, Powerline Truck Hacking, Two Tools for PLC for Trucks.
[00:07.140 --> 00:13.840]  We're going to talk to you today for about an hour, you know, who are we, what is PLC,
[00:13.840 --> 00:19.280]  how do you interface with PLC, what are these two tools, PLC for Trucks, GR2497,
[00:19.900 --> 00:25.800]  how can you adapt what you got onto the PLC connection. We discovered an issue,
[00:25.800 --> 00:29.980]  we're going to discuss that issue and the impacts, and then we'll show you some future work.
[00:30.640 --> 00:36.360]  So first up about us, I'm Ben Gardner, I'm a researcher with the National Motor Freight
[00:36.360 --> 00:41.660]  Traffic Association, previously done embedded systems development, reverse engineering,
[00:41.660 --> 00:46.560]  I've been an instructor at the Cybertruck Challenge and plan to, when it ever comes back,
[00:46.560 --> 00:53.440]  I also volunteer at DEF CON and SAE. Hi, I'm Chris Poore, an electrical engineer who has
[00:53.440 --> 00:58.180]  been hacking things and helping people get away with it for more years than I can count on these
[00:58.180 --> 01:03.100]  blood-stained hands. I work at Assured Information Security, headquartered in Rome,
[01:03.100 --> 01:09.700]  New York, with locations all over the U.S. AIS strives to be a driving force for technology and
[01:09.700 --> 01:16.220]  national security and has the combined professional experience that I believe is rivaled only by the
[01:16.220 --> 01:26.100]  space program. Contact AIS today. Next slide, please. It's not just a two-person effort,
[01:26.100 --> 01:30.780]  we're part of a much larger team, a great team that we've been privileged to be a part of,
[01:30.780 --> 01:36.260]  comprised of Dan Salone, Christopher Poore, who you now know, Eric Thayer, all of AIS,
[01:36.700 --> 01:42.560]  and myself from the NMFTA. Also, this research would not have been possible without the support
[01:42.560 --> 01:47.120]  of the Motor Freight Carrier members of the NMFTA, who sponsored us with access to their
[01:47.120 --> 01:52.560]  facilities and to their equipment, and thank you for that. First up, what is power line
[01:52.560 --> 01:57.880]  communications? Generally speaking, any time you're putting data onto lines that are intended
[01:57.880 --> 02:03.880]  for power, you're doing power line communications. You might know some technologies that fall into
[02:03.880 --> 02:08.260]  this class, such as Green PHY and Home Plug. There's an entire interoperable family of
[02:08.260 --> 02:15.340]  technologies in IEEE 1901. The technology is found in automotive, most commonly under SAEJ
[02:15.340 --> 02:20.120]  1772, which is for plug-in electric vehicle charging, and there was some really interesting
[02:20.120 --> 02:25.740]  work by Baker and Martinovic at USENIX 19, where they showed that they could remotely read traffic
[02:26.340 --> 02:30.700]  between the plug-in electric connection of a vehicle and the charger. But today, we're not
[02:30.700 --> 02:36.060]  talking about plug-in electric vehicles, we're talking about trucks. So let's rewind the clock
[02:36.240 --> 02:41.700]  a little bit, maybe a couple decades, and look at what trucks looked like around 1997. There were
[02:42.560 --> 02:47.240]  anti-lock braking, ABS systems, on trailers and on tractors, and these ABS systems are quite
[02:47.240 --> 02:54.640]  important to prevent rolls and reduce braking distance. It's really important
[02:54.640 --> 03:00.500]  for safety. So at the time, there was only a warning on the side of the trailer that showed
[03:00.500 --> 03:05.240]  you if the ABS was malfunctioning. There are regulators and fleet safety managers that really
[03:05.240 --> 03:10.220]  wanted to have some kind of a dash display that would show the driver if there was a problem with
[03:10.220 --> 03:15.460]  the trailer ABS. And this, of course, would help make sure that ABS is functioning and everyone
[03:15.460 --> 03:22.440]  would stay safe. Now let's look at how these trailers and tractors were connected. So back
[03:22.440 --> 03:27.860]  then, and actually as it is today, trailers and tractors are connected with a J560 connector.
[03:27.860 --> 03:35.340]  Here you can see that green pigtailed cable plugging into a bulkhead jack there. And that's
[03:35.460 --> 03:41.720]  a seven-way connector. You can also see a red and a blue cable behind the bulkhead here. Those are
[03:41.720 --> 03:50.060]  actually pressurized air, whereas the green cable here, this is electrical. So back then,
[03:50.060 --> 03:55.520]  they had this tractor-trailer connector. You can see a breakout here of the J560. It's got
[03:55.520 --> 04:02.800]  tail lights, right turn, left turn, brake lights, a ground connector, and then this power for ABS
[04:02.800 --> 04:08.720]  and auxiliary power. So it's a fully populated connector. There's no room for anything else, but
[04:08.720 --> 04:14.440]  still, regulators and safety managers really wanted to have a way to show the driver when
[04:14.440 --> 04:19.320]  something was failing. Now an obvious option is to add another connector, but unfortunately,
[04:19.320 --> 04:24.560]  you know, for fleets, the lifetime of trailer equipment is very long and the cost of retrofitting
[04:24.560 --> 04:30.200]  is very high. So the industry took it upon themselves to design a technology that would
[04:30.200 --> 04:36.980]  let them send this ABS fault data up into the tractor without adding a new connector.
[04:36.980 --> 04:43.000]  And at the same time, there was a lot of other technologies that people wanted to get data from
[04:43.000 --> 04:49.740]  the trailer into the tractor, and there was things like axle weight, door latch, yaw sensors, and
[04:49.740 --> 04:55.500]  things like that. So it was hoped that this technology could carry all sorts of information
[04:55.500 --> 05:01.460]  up from the trailer to the tractor, not just the ABS fault info. Around June 1998, ATATMC actually
[05:01.460 --> 05:06.060]  approved PLC for trucks. This is the American Trucking Association's Technical Maintenance
[05:06.060 --> 05:10.300]  Council. They are responsible for making recommended practices in the commercial vehicle
[05:10.300 --> 05:20.280]  space. And eventually, SAE published J2497 in 2002. And what they did was add high-frequency
[05:21.700 --> 05:26.860]  signals onto these power lines that run the length of the truck. So they would couple them
[05:26.860 --> 05:32.080]  onto their either transformer or capacitor, just AC-coupled, and send these high-frequency
[05:32.080 --> 05:39.780]  signals with enough of a voltage that they would propagate. Now, there was an issue with
[05:39.780 --> 05:45.300]  PLC for trucks that was patent. It was actually patent incumbent. And at the time that they
[05:45.300 --> 05:50.220]  started the work on this, they didn't know. Eventually, it became known, and SAE actually,
[05:50.220 --> 05:56.800]  at one point, just canceled the working group to create J2497. And eventually, it was resolved.
[05:56.800 --> 06:00.600]  The technology was patented for a long time, and there were royalties that had to be paid, but the
[06:02.480 --> 06:08.380]  standard did go forward. Now, if you go to SAA meetings or ATATMC meetings like I do,
[06:08.380 --> 06:13.680]  you've probably seen these patent disclosure and IP statements at the beginning of the meetings.
[06:13.680 --> 06:18.980]  I've been told that for ATATMC, those passages actually exist because of what happened with
[06:18.980 --> 06:26.440]  PLC for trucks, whereas with SAE, those statements actually predated the PLC for trucks issue.
[06:27.060 --> 06:31.740]  So it took the industry a while to get it done. It was quite complicated. There was a lot of tests
[06:31.740 --> 06:36.160]  that happened over the winter and otherwise. And as I mentioned, there was other technologies
[06:36.160 --> 06:41.360]  that wanted to get like axle weighing and door sensors and things like that up from the trailer
[06:41.360 --> 06:47.580]  into the tractor. So they had interoperability tests. And it ended up being... eventually,
[06:47.580 --> 06:52.260]  it was deployed, but it was quite complicated to get it to that point. So the news media
[06:53.480 --> 06:59.200]  has been seen to call this technology expensive or complicated. There's a funny quote right here
[06:59.200 --> 07:03.880]  where someone's saying the most expensive light bulb in history. So it is funny to look at the
[07:03.880 --> 07:09.420]  technology that way. But it's also important to recognize that the calculus that the fleets were
[07:09.420 --> 07:13.640]  looking at was whether they would have to retrofit all their trailers, which typically have, you know,
[07:13.640 --> 07:21.020]  30 year service lifetimes, just to get another light up into the cab. So creating this technology,
[07:21.020 --> 07:25.880]  even though it seems like it was an expensive light bulb, still, from their point of view,
[07:25.880 --> 07:32.320]  what they wanted was cheaper. And that's going to be true today as it was back then. The trailers
[07:32.320 --> 07:37.380]  last for a very long time. The connectors are still the J560 connector. And trying to change
[07:37.380 --> 07:44.000]  any of that might prove to be more expensive than anyone would want to spend. So now you know a lot
[07:44.000 --> 07:48.700]  of the history about J2497 and why it came about and why are we sending these high frequency signals
[07:48.700 --> 07:55.060]  on power lines. Let's talk more about what it is, how it's put together. You can think of J2497
[07:55.060 --> 08:02.460]  like an alternate physical layer for J1708. And we're not going to go into J17 a lot because
[08:02.460 --> 08:07.380]  there's another talk that will give you lots of details on it. Suffice it to say that it's a
[08:07.380 --> 08:16.280]  heavy vehicle network that predates J1939. J2497 has its own arbitration scheme that it
[08:16.280 --> 08:23.740]  employs around J1708. The PLC for trucks 2497 is always 9600 bauds. And the way it takes these
[08:23.740 --> 08:31.040]  1708 signals is it'll actually encode them into spread spectrum chirps. So another way to think
[08:31.040 --> 08:39.340]  about 2497 is by an analogy. You can see a couple analogies that I'm making here. You know J1939
[08:39.340 --> 08:47.000]  is a lot like J1587. And J1939 can sit on top of high speed or low speed canned buses, twisted or
[08:48.060 --> 08:57.840]  unshielded. So similarly can J1587 sit on top of either J2497 or just J1708. And you'll probably
[08:57.840 --> 09:02.980]  have diagnostics or some other applications on top of those. Which if you're not an automotive
[09:02.980 --> 09:10.020]  person you can think of it by an analogy to DNS which is built on top of UDP. And UDP IP can run
[09:10.020 --> 09:18.400]  either like ethernet or 802.11 infrared for example. So let's talk a little bit more about
[09:18.400 --> 09:24.940]  these spread spectrum chirps. The specification of J2497 by SAE actually includes a definition
[09:24.940 --> 09:31.260]  of the chirp. And they have to sweep from 200 to 400 kilohertz, then from 400 to 100 kilohertz,
[09:31.260 --> 09:36.180]  and then from 100 to 2 or 3 kilohertz. You can see a picture here of a rendering of a couple
[09:36.180 --> 09:42.280]  possible chirps. Different possibilities result by how you treat these discontinuities here.
[09:42.420 --> 09:49.260]  The chirps themselves are about 100 microseconds total. They start and end at value zero so that
[09:49.260 --> 09:52.960]  they can be concatenated. And when they're transmitted they should be transmitted in
[09:52.960 --> 09:58.240]  amplitude between 2.5 to 7 volts peak-to-peak according to the spec. Now in practice
[09:59.540 --> 10:04.360]  the transmitters on trailer equipment tend to send them even higher than 7 volts peak-to-peak
[10:04.360 --> 10:09.780]  just to make sure that they'll make it from one end of the tractor trailer to the other.
[10:11.420 --> 10:16.300]  The chirps are put together into frame encodings that will let them actually send
[10:16.820 --> 10:21.740]  J1708 frames. And the way the frames are encoded is broken up into a preamble and a body.
[10:21.760 --> 10:28.160]  The purpose of the preamble is there to realize that alternate arbitration method so that if two
[10:28.160 --> 10:32.580]  PLC devices are trying to talk at the same time there's a way to determine who has the highest
[10:32.580 --> 10:39.080]  priority and which one should back off. It's very similar to CAN. It involves that very first
[10:39.080 --> 10:47.260]  byte being sent and the lower byte is the higher priority. So here you can see two renderings of
[10:47.260 --> 10:55.800]  frames. The first being OA00, the second being OBFF. The OA00 frame and the OBFF frame are the
[10:55.800 --> 11:03.540]  ADS fault information that we talked about, the impetus for J2497. So in the preamble you can see
[11:03.540 --> 11:09.100]  that the messages, the actual chirps have delays in between them. And this is because the chirps
[11:09.100 --> 11:15.920]  are 100 microseconds but the time for the symbols is 104 microseconds, these little gaps. In the
[11:15.920 --> 11:23.480]  preamble the presence of the chirp indicates, you know, the logic value. So logic 0 means chirp
[11:23.480 --> 11:29.580]  present, logic 1 is chirp absent. But then when you get into the body it's actually 100
[11:29.580 --> 11:38.240]  microseconds with no gaps and the encoding is actually determined by phase. So this is phase
[11:38.240 --> 11:44.740]  shift keying in the body. The phase of logic 0 is arbitrary per device and it's actually given by
[11:44.740 --> 11:50.880]  the phase that's transmitted here in the amplitude shift keying section. There's a checksum
[11:50.880 --> 11:55.940]  at the end and then there's all these sync bits you can see in orange and in green.
[11:56.440 --> 12:01.620]  And some of these sizes are variable so there could be one to two initial symbols and there
[12:01.620 --> 12:14.080]  could be zero to four gap symbols. So why is it like that? Well J2497 was designed for J1708.
[12:14.420 --> 12:19.420]  This whole PLC for trucks scheme was actually accomplished by a particular piece of
[12:19.420 --> 12:28.960]  silicon, the Intelon SSC P485. And this particular chip was designed to take J1708 frames and wrap
[12:28.960 --> 12:34.220]  them around with some extra information and re-encode them into these spread spectrum chirps.
[12:34.220 --> 12:41.860]  So the Intelon P485 actually adds, you know, these sync bits and adds all the preamble highlighted
[12:41.860 --> 12:49.280]  here in orange. It will then send, you know, the actual encoded information in chirps as the body
[12:49.280 --> 12:55.180]  which matches exactly what you would see on the J1708 line. And then it adds these terminators with
[12:55.180 --> 13:04.040]  the gaps and the sync bits. So the checksum is actually part of J1708 and part of J2497.
[13:04.780 --> 13:11.680]  And you can see there's a duplication of MIDs. You can think of MIDs like arbitration IDs
[13:11.680 --> 13:17.980]  in CAN. It's that first byte. It determines arbitration on the bus and the data is duplicated
[13:18.660 --> 13:27.160]  twice. It turns out that this information here in the preamble is used for arbitration of the PLC bus
[13:27.160 --> 13:33.860]  only. And what gets sent on J1708 is this byte that's put right here, which means that you can
[13:33.860 --> 13:39.700]  send things where those two don't equal each other. And you can override priority. So you
[13:39.700 --> 13:47.100]  could send a very low priority MID with an all zero PLC MID and it would margin on top of anyone
[13:47.100 --> 13:54.720]  else that was talking on PLC. So a little bit about J1587. This is that next layer above. You
[13:54.720 --> 14:01.560]  can think of it akin to J1939. If you look at the J1587 spec, there's a lot of really interesting
[14:01.560 --> 14:06.840]  highlights. They say that you shouldn't send more than 21 bytes at a time unless the vehicle is
[14:06.840 --> 14:12.680]  stationary. I wonder what happens if you don't. There's a factory test MID that should never be
[14:12.680 --> 14:19.400]  sent by any vehicle system. There are bridging and forwarding schemes defined in the spec. There's a
[14:19.400 --> 14:26.360]  dynamic address claim. There are cold and warm reset commands and lots of support for interesting
[14:26.360 --> 14:30.960]  kind of peripherals on commercial vehicles like toll systems and display signage and climate
[14:30.960 --> 14:37.940]  control. Now for some more details on how to decode J1587 automatically, please see our team's
[14:37.940 --> 14:44.740]  presentation, which should be up today, or look at the pretty J1587 repository.
[14:46.140 --> 14:50.980]  Even though J1587 defines a lot of interesting things that could be in there,
[14:50.980 --> 14:56.820]  all we've seen in our testing for the most part is the ABS fault lamp on and off messages and
[14:56.820 --> 15:04.740]  manufactured diagnostic messages. There was a report by the FMCSA that suggested that there
[15:04.740 --> 15:13.220]  should also be axleway yaw sensor and door latch sensor traffic on the PLC bus, but we haven't run
[15:13.220 --> 15:24.960]  into it yet. So how do you connect to PLC? There are some great options out there. The DG Technologies
[15:24.960 --> 15:33.360]  PLC TESCON is very rugged and reliable. I love mine. There is also a NEXIC PLC adapter, which
[15:33.360 --> 15:40.000]  has the advantage of being able to go in line on a cable, so you can you can test it in place.
[15:40.280 --> 15:47.180]  The problem with these sort of classic diagnostic adapters is that they aren't cheap. You will need
[15:47.180 --> 15:53.760]  them for running manufactured diagnostic tools though. And also the Intelon P485, I'm told,
[15:53.760 --> 15:57.500]  is becoming harder to source, which is not going to help with the cost of these tools.
[15:57.980 --> 16:03.200]  Finally, the limitation of these tools is that you can't do anything strange to PLC with these
[16:03.200 --> 16:09.680]  tools, because they just have an Intelon P485 chip in them, and so you can't make arbitrary
[16:09.680 --> 16:18.140]  PLC waveforms. For example, you can't do different PLC MID from a J1708 MID on the bus.
[16:19.220 --> 16:26.940]  So how do you interface with J1708 so that you can interface with PLC? The first one up is another
[16:26.940 --> 16:34.480]  one of those RP-1210 adapters, such as the Digitech DPA4, DPA5, or an EXIC USB link.
[16:34.480 --> 16:41.700]  And these things are necessary for the manufacturer diagnostics. An option that I really like,
[16:41.700 --> 16:46.900]  that's really cool, that was presented here at DEF CON 24 is the TruckDuck, which is a beaglebone
[16:46.900 --> 16:54.660]  cape by 6V and Haystack. There's been some revisions to this board since the DEF CON 24
[16:54.660 --> 17:01.640]  presentation. There's the 1.5 EET version and the Mega version. These beaglebone capes enable
[17:01.640 --> 17:07.920]  communication with both J1939, or any Canon network actually, and J1708 networks through
[17:07.920 --> 17:14.200]  the PiHV networks module that Haystack authored. And we are going to talk about some ways to use
[17:14.200 --> 17:21.920]  these to write PLC. So our PLC writing tool, what we wanted was something to be low cost.
[17:21.920 --> 17:27.540]  We wanted it to be open. We wanted it to be capable of doing weird things. We weren't so
[17:27.540 --> 17:34.360]  concerned about arbitration. The J1708 stack that Haystack put together for the TruckDuck
[17:34.360 --> 17:39.680]  originally didn't have any arbitration, just had frame detect, and it works fairly well on systems
[17:39.680 --> 17:48.320]  that aren't highly loaded. And we didn't want to worry about getting read in right now, and the
[17:48.320 --> 17:53.800]  reason for that you'll see will be clear later. So our approach that we elected, mostly because
[17:53.800 --> 17:58.960]  we're biased and we like the TruckDuck, is let's make some small mods to the TruckDuck and push
[17:58.960 --> 18:05.720]  them upstream and try to stick with very small BOM changes, and hopefully 6V can integrate those
[18:05.720 --> 18:15.340]  into the next Mega Mega EET version of the TruckDuck. So, Bitbanging PWM on the PRU. Bitbanging
[18:15.340 --> 18:21.500]  is the process of toggling a GPIO in order to create whatever protocol you're after. GPIOs are
[18:21.500 --> 18:27.160]  general purpose input output pins, of which there are many on the BeagleBOM, and the PRU is a
[18:27.160 --> 18:33.480]  programmable real-time unit on the BeagleBOM. It runs jitter-free, like deterministic code with no
[18:33.480 --> 18:39.300]  interrupts stopping execution at 200 megahertz, which is plenty for the 400 kilohertz-ish
[18:39.300 --> 18:47.060]  signal of PLC. And also the PRU was used originally on the TruckDuck for the J1708 stack itself,
[18:47.060 --> 18:52.520]  so there's already a precedent there for using the PRU in this system.
[18:53.180 --> 19:00.200]  It turns out that the TruckDuck J1708 channel 2 has pretty much been broken since release,
[19:00.200 --> 19:07.020]  which is actually good for us because it lets us reuse, repurpose, one of the PRU cores for
[19:07.020 --> 19:16.540]  the PLC application instead. And in trying to find pins, we needed to find one that we knew
[19:16.540 --> 19:22.040]  we could bitbang from the PRU, which is a certain class of pins. But we also wanted to eventually
[19:22.040 --> 19:28.280]  maybe get rid of the PRU, if possible, and use the integrated PWM unit in the BeagleBOM, although
[19:28.280 --> 19:34.040]  that hasn't been done yet. So trying to find the pin that would work was, you know, one of
[19:34.040 --> 19:39.280]  these fun processes. I found it best to just do it with markers. We wanted to make sure that it
[19:39.280 --> 19:44.300]  could be accessed from the PRU. It could migrate to PWM. We wanted to make sure it didn't conflict
[19:44.300 --> 19:50.940]  with any other TruckDuck pins. So for synthesizing PLC, we settled eventually on P928. We had a
[19:50.940 --> 19:59.040]  backup. And then we also planned for doing frame detect and PLC read via an ADC, but we haven't
[19:59.040 --> 20:05.700]  implement that. That's just kind of allocated for later. So in creating PLC signals, there's two
[20:05.700 --> 20:11.340]  main parts. You have to synthesize this PLC with PWM, and then you have to couple this signal
[20:11.340 --> 20:16.200]  that you've created onto the PLC network. So there's these two clouds that we're going to reveal.
[20:17.920 --> 20:23.020]  I don't often do this, but I thought I would this time. I would try the dumbest thing first,
[20:23.020 --> 20:27.880]  and my friends will tell you that I'm not very good at doing that, but I did it this time. The
[20:27.880 --> 20:33.660]  first thing we tried was the dumbest PWM possible. You just turn it on when the signal that you're
[20:33.660 --> 20:37.560]  trying to realize is above zero, and turn it off when the signal you're trying to realize is below
[20:37.560 --> 20:42.880]  zero. So you can see that picture here. The orange waveform is the dumb PWM, and the blue waveform
[20:42.880 --> 20:50.180]  is the true CHIRP. And it turns out that actually worked. So we said yay and moved on. The next part
[20:50.180 --> 20:56.140]  was coupling. And you can see here in the DGTech PLC test con, the coupling network they created
[20:56.140 --> 21:02.980]  is just gorgeous. And compared to what we were using, it is amazing because we found out that
[21:02.980 --> 21:08.880]  100 nanofarad capacitor was enough, and that was our filtering as well. So the dumbest filtering
[21:08.880 --> 21:15.560]  and the dumbest PWM got us what we needed, and we moved on. The results were pretty good,
[21:15.560 --> 21:22.220]  actually. We did run into one issue with undocumented cycle counts for some of the
[21:22.220 --> 21:27.320]  instructions that we we had to use in assembly, but the results were fine. You can see down here
[21:27.320 --> 21:34.080]  the orange signal is a recording on an oscilloscope of the PLC signal that we synthesized
[21:34.080 --> 21:41.000]  after filtering on a receiver. Same with the purple. This is just a larger zoomed out trace.
[21:41.260 --> 21:47.140]  So this is post-filtering of the signal that we realized. The signal that we realized is much more
[21:47.140 --> 21:51.840]  like these square waves up here in the tuning edge delays diagram. And this is just a representation
[21:51.840 --> 21:56.580]  of how we had to tune some of the assembly instructions to make sure that the signal would
[21:56.580 --> 22:02.720]  line up, you know, all the way into the realization like bit 54 of the PLC chirp train that we had to
[22:02.720 --> 22:12.480]  create. So it worked pretty well. The code. You can get this tool. It's MIT licensed. It's available
[22:12.480 --> 22:21.160]  on GitHub as of today. What it does is it adds a new J1708 server. That's the way that the 1708
[22:21.160 --> 22:28.840]  was set up on the truck ducks is they receive and send UDP frames and will send or receive those
[22:28.840 --> 22:34.280]  onto J1708. What we did was create a whole new one that's completely compatible, but what it
[22:34.280 --> 22:43.080]  does is send PLC signals instead. We also created some command line utilities. The network, the
[22:43.080 --> 22:48.860]  Pi HV networks that Haystack created has a really nice programming interface for Python, but I just
[22:48.860 --> 22:55.120]  like to have really simple command line tools like dump and send. So we drafted those and they're
[22:55.120 --> 23:03.160]  compatible with the existing stack as well. And so to get your truck ducks to connect to PLC,
[23:03.160 --> 23:08.300]  you actually do need to do some PCB changes to your truck duck for now until 6V rolls us into
[23:08.300 --> 23:14.420]  the next revision. And this led to probably one of my favorite kind of bodge jobs because I love
[23:14.420 --> 23:20.140]  to do rework of PCBs and I also really like it when things have to be MacGyvered. When we were
[23:20.140 --> 23:26.120]  connecting this up to PLC, we discovered that it would work when there was a really long length of
[23:26.120 --> 23:31.460]  cable in between the power supply of the truck duck and the point where we were coupling to the
[23:31.460 --> 23:35.400]  network. And if we didn't have that long piece of cable, the truck duck power supply just seemed to
[23:35.400 --> 23:43.220]  attenuate the PLC signals to almost nothing, which led me to this great bodge job right here where I
[23:43.220 --> 23:48.120]  wrapped 40 inches of wire and soldered that down to the board in between the input to the power
[23:48.120 --> 23:56.600]  supply and the connector. And that actually solved the problem, which is fun. Okay, so next up we're
[23:56.600 --> 24:01.260]  going to show you how you can use some adapters to connect your truck duck up to the power lines.
[24:01.260 --> 24:08.560]  There's a lot of different options. The first is this J560 to DB15 in Deutsch 2-pin. So these
[24:08.560 --> 24:13.880]  DB15 connectors, you can find them in a lot of different diagnostics adapters. The DPA4 and the
[24:13.880 --> 24:18.280]  truck duck both have them. This is a 560 connector here, which is useful to be plugged into the back
[24:18.280 --> 24:23.000]  of your tractor. You can also plug into the back of your trailer if you have an adapter to connect
[24:23.000 --> 24:29.220]  to the batteries up here on the Deutsch 2-pin, and the whole set is in the DG Tech PLC Tescon.
[24:29.560 --> 24:36.060]  Next up is these battery clip, the DB15 adapters, and these ones can be found in the Nexic adapter
[24:36.060 --> 24:43.060]  sets on the internet. There's also these Y adapters for J560, where they give you a Deutsch
[24:43.060 --> 24:49.940]  9-pin connector in line with two J560 connectors, so these can be used in line with a tractor and
[24:49.940 --> 24:54.680]  trailer that are connected. You've got to watch out that some of these actually do contain an
[24:54.680 --> 25:03.680]  Intelon P485, and what they're doing is converting PLC to J1708 and routing that to the J1708 pins
[25:03.680 --> 25:09.820]  instead of PLC onto the power pins. Another one that's useful is one of these inline
[25:09.820 --> 25:16.600]  jack and plug, which is very similar to the previous one. None of these have the Intelon P485
[25:16.600 --> 25:24.760]  inside them. You can also build your own umbilical, so these J560 plugs, you can take them apart by
[25:24.760 --> 25:29.620]  removing the set screw, and you can wire any kind of a pigtail you like. I like to use these Deutsch
[25:29.620 --> 25:34.260]  2 pins because they work with the DG Tech sets, and then you can close it all back up and you can
[25:34.260 --> 25:43.300]  have a connector that can be used with a tractor and trailer connected. So we also created a PLC
[25:43.300 --> 25:51.220]  reading tool, and Chris Poore is going to tell you some more details about that. Chris? Thanks, Ben.
[25:51.360 --> 25:58.680]  One of our goals was to develop a low-cost tool for reading J2497 messages with SDRs and
[25:58.680 --> 26:04.320]  open source software. We wanted a solution to let just about anybody tap into a line and see
[26:04.320 --> 26:16.940]  messages all for little cost. Next slide, please. Again, the J2497 signals primarily consist of a
[26:16.940 --> 26:23.540]  series of 100 microsecond chirps that start at 203 kilohertz, ramp up to 400 kilohertz, quickly
[26:23.540 --> 26:31.380]  drop down to 100 kilohertz, and back to 203 kilohertz. The 100 to 400 kilohertz frequency
[26:31.380 --> 26:40.460]  range is lower than most SDRs can handle. For example, the starting frequency of the RTL2832U
[26:40.460 --> 26:48.720]  dongles vary depending on the model, but they can range from 500 kilohertz to around 50 megahertz.
[26:50.060 --> 26:59.920]  Next slide, please. To get around this problem, we used up converters. The Hammett up up converter
[26:59.920 --> 27:05.860]  will take our signal and mix it with an intermediate frequency of 125 megahertz.
[27:06.120 --> 27:14.700]  I believe the SPIverter uses 120 megahertz. Once it's near 125 megahertz, we can receive it with
[27:14.700 --> 27:21.260]  radios and begin to condition the signal in software. We improved the quality of the signal
[27:21.260 --> 27:29.700]  if we didn't tune our radio directly on 125 megahertz, but instead at 126. This allowed
[27:29.700 --> 27:35.620]  us to use a bandpass filter to get rid of a lot of the DC noise associated with the Hammett up.
[27:36.460 --> 27:38.240]  Next slide, please.
[27:40.240 --> 27:46.220]  We achieved most of our success with an RTL and a Hammett up, but there are solutions out there
[27:46.220 --> 27:52.600]  that could be promising that don't use up converters. We tried the Lime SDR, which starts
[27:52.600 --> 27:59.300]  at 100 kilohertz, but the gain and performance down at those frequencies was too low for us.
[27:59.460 --> 28:06.060]  You can find schematics online for modifying RTL SDRs to get a lower starting frequency.
[28:06.060 --> 28:11.900]  They also make some that have a direct receive mode that can tune down to 500 kilohertz,
[28:11.900 --> 28:16.720]  but they say the performance is reduced when operating them there.
[28:17.740 --> 28:23.040]  The AirSpy HF Plus is supposed to start at 9 kilohertz,
[28:23.040 --> 28:28.440]  but it might not have the bandwidth to support the J2497 chirps.
[28:29.520 --> 28:34.580]  You might have some luck with oscilloscopes, but then the price starts to go up.
[28:34.580 --> 28:39.780]  The ADOM2000 is a cheaper option you might want to consider.
[28:41.280 --> 28:43.140]  Next slide, please.
[28:44.420 --> 28:51.540]  Back to our setup. When tapped to the line, we used a coupling adapter to remove the 12-volt
[28:51.540 --> 28:58.480]  DC offset that exists. This was to be on the safe side and avoid any chance of damaging our
[28:58.480 --> 29:07.220]  upconverter. Next, the output of the upconverter went to the RTL SDR and was sampled and filtered
[29:07.220 --> 29:13.490]  in GNU Radio, producing a J1708-looking message like you see in the bottom right.
[29:14.540 --> 29:18.740]  Note how the preamble has visible silent periods,
[29:18.740 --> 29:23.760]  and the body is the continuous section at the end of the message.
[29:25.360 --> 29:27.240]  Next slide, please.
[29:29.240 --> 29:36.080]  We developed three methods for demodulating those signals into bits. One method examines the
[29:36.080 --> 29:43.060]  instantaneous frequency. The other two rely on correlating the signal with specific sequences.
[29:43.100 --> 29:48.480]  I'll go over them in the next few slides. Next slide, please.
[29:50.400 --> 29:56.660]  Our first attempts took advantage of GNU Radio's quadrature demod block to produce the plot you
[29:56.660 --> 30:02.500]  see in the bottom right. The sawtooth pattern you see down there represents the frequency over
[30:02.500 --> 30:09.800]  time for chirps in the body of the message. The circled spikes indicate sudden changes in phase
[30:09.800 --> 30:16.420]  at the start of a new chirp. This is what we use to distinguish the ones and zeros.
[30:17.160 --> 30:24.740]  No change in phase means keeps the value of the previous bit, while phase change means flip the
[30:24.740 --> 30:31.580]  bit. We framed the start and stop of each message based on the amplitude and tried to ignore the
[30:31.580 --> 30:38.340]  preamble sections of each message since the body contains the whole J1708 message anyway.
[30:39.700 --> 30:41.400]  Next slide, please.
[30:43.560 --> 30:47.440]  We started developing alternative methods because the previous one
[30:47.440 --> 30:53.480]  did not work well with noise and relied heavily on a consistent signal amplitude.
[30:53.480 --> 30:58.440]  So to get around that, we correlated the signal with a 203 kilohertz reference.
[30:59.600 --> 31:06.580]  Now, 203 kilohertz is the precise frequency where each chirp begins. If there's no phase change,
[31:06.580 --> 31:12.960]  there's a smooth 203 kilohertz signal, which are the higher peaks you see in the output down there.
[31:13.680 --> 31:19.160]  However, when there's a phase change present, the frequency gets disrupted for a short period of
[31:19.160 --> 31:24.580]  time. It results in a value close to zero when correlated with the reference.
[31:25.320 --> 31:28.980]  That's why you kind of see those mini spikes where it's ramping up and down
[31:29.540 --> 31:34.860]  as it approaches the location where 203 kilohertz should be in the chirp.
[31:35.820 --> 31:42.600]  Likewise, anything outside the message, like the noise, is going to be reduced to a value close to
[31:42.600 --> 31:49.600]  zero. We use a moving average filter on the correlation output to frame the message and
[31:49.600 --> 31:59.820]  ignore the preamble part of it. Next slide, please. Now, for situations where the signal
[31:59.820 --> 32:05.280]  is completely buried in the noise, the previous two methods are not very effective.
[32:05.280 --> 32:09.820]  Instead, we tried a new method, which begins by correlating the signal
[32:09.820 --> 32:14.360]  with a Python-generated chirp designed to mimic a real one.
[32:14.460 --> 32:20.520]  The result produces much larger peaks, like you see down there, which helps distinguish it from
[32:20.520 --> 32:27.480]  the noise. We use this technique to frame the message and reuse the 203 kilohertz reference
[32:27.480 --> 32:34.500]  in the previous method to distinguish the ones and zeros. Next slide, please.
[32:35.800 --> 32:43.320]  Next slide, please. We call it all GRJ2497. It contains the blocks and flow graphs that will
[32:43.320 --> 32:49.600]  read the traffic and print out messages like what you see on the right. The values for the MID,
[32:49.600 --> 32:55.860]  data, and checksum are pulled right from the messages. Additionally, there is an option
[32:55.860 --> 33:03.040]  built into the blocks to send the messages in hex over to a UDP port for other potential tools to
[33:03.040 --> 33:11.960]  use. Now, back to Ben to continue on. Thanks, Chris. So, you've got GENIE radio, and you can
[33:11.960 --> 33:17.840]  now read your PLC signals, but how do you connect your Hammet up or some direct receive receiver
[33:17.840 --> 33:24.740]  onto PLC? Turns out, once again, just 100 nanofarad capacitor is going to do the trick.
[33:24.880 --> 33:29.900]  I have used and like to use the 100 volt ones just to be safe, because we don't really want
[33:29.900 --> 33:35.080]  to get battery currents connected to our receivers. And then you just need a way to connect
[33:35.080 --> 33:42.020]  those PLC wires onto this coupling network. So, all of those previous adapters that we talked
[33:42.020 --> 33:47.060]  about all apply in this case, but then how do you connect the wires up? And I think one of the
[33:47.060 --> 33:52.480]  nice solutions we came up with is modifying these Balan19 adapters. So, you can actually
[33:52.480 --> 33:58.620]  take the transformer off of the board and cut the trace right here at the back,
[33:58.620 --> 34:05.700]  replace that transformer with a surface mount capacitor, bridge the ground here, and then cover
[34:05.700 --> 34:12.420]  it all with solder resist to avoid ever touching 12 volt at back battery currents for trucks.
[34:13.440 --> 34:19.200]  Another one that's an adapter that works is an antenna. You actually can read these signals
[34:19.200 --> 34:25.920]  wirelessly. We experimented with a whole bunch of different antennas, but we found that this form
[34:25.920 --> 34:32.680]  of active antenna, pictured here, works pretty good and is pretty darn cheap. The power supply
[34:32.680 --> 34:39.700]  that's here is fine, but it works well as well if you connect a 9 volt battery to it instead.
[34:39.760 --> 34:44.480]  And we believe that there's a lot more options out there because really anything that's made for
[34:44.480 --> 34:51.400]  2200 meters or low FER is in the right band. But we stuck with portable options because a lot of
[34:51.400 --> 34:55.940]  low FER and 2200 meter stuff is giant masts and you're not going to move that around with you,
[34:55.940 --> 35:02.380]  but there are loops and whips and mini whips. But really if you just want to do quick and dirty,
[35:02.380 --> 35:08.160]  these mini whips work really great for the price. Over here you can actually see, you know, we're
[35:08.160 --> 35:15.160]  receiving a pretty clear PLC signal on top of the background noise using just this mini whip taped
[35:15.160 --> 35:21.080]  to the side of a box next to a truck. So we're able to read these signals wirelessly, but
[35:21.080 --> 35:28.640]  how far? In our testing we can reliably receive six feet away from a position next to the gap
[35:28.640 --> 35:34.920]  between the tractor and the trailer. Now this was using our first version of the GNU radio receiver,
[35:34.920 --> 35:39.820]  the one that does the phase measurements and not the new cool stuff that Chris talked about
[35:39.820 --> 35:47.740]  with correlation. So we feel pretty confident this can be extended. We don't know how far and, you
[35:47.740 --> 35:55.740]  more testing, we're going to find out. Why do we think this works? It's a bit strange because,
[35:55.740 --> 36:00.660]  you know, these trailers, or maybe the long ones that we were testing on, were 40 feet.
[36:01.060 --> 36:07.180]  And a half wave, you know, resonator at 40 feet is really only 12 megahertz, which is
[36:07.180 --> 36:14.360]  way, way above the 400 kilohertz top end of PLC for trucks. So it really shouldn't be
[36:15.060 --> 36:21.120]  a good radiator. But when we tested it, it certainly is good enough at this point. And
[36:21.120 --> 36:29.000]  we think that may be a combination of factors, but possibly primarily due to that very large
[36:29.000 --> 36:34.020]  voltage that they transmit, that these devices transmit at, to make sure they can make it across
[36:34.020 --> 36:42.380]  the whole range of the tractor and the trailer. So yeah, the long wires, the high transmit voltages,
[36:42.380 --> 36:48.260]  I think also contributing this is maybe PLC transmitters are actually left alone to be
[36:48.260 --> 36:56.860]  noisy. The spec for J2497 allows any conducted noise to be beyond any other restrictions.
[36:56.880 --> 37:05.180]  And then also FCC's regulations on unintentional radiators actually exempt vehicles,
[37:05.180 --> 37:09.980]  any digital device utilized exclusively in any transportation vehicle from the unintended
[37:09.980 --> 37:16.180]  radiator status. Now they do still have to, you know, turn off if they're found to be in violation,
[37:16.180 --> 37:21.560]  but it's hard to understand how that could be enforced with a large moving vehicle. So it seems
[37:21.560 --> 37:28.160]  like maybe these are radiators that are beyond spec and no one's been testing for them because
[37:28.160 --> 37:35.860]  they're exempt or because it's in spec. There are some impacts to this, but the good news is
[37:35.860 --> 37:41.900]  the impacts aren't very large. It's really a minor impact. On trailers, as we mentioned, really the
[37:41.900 --> 37:47.560]  main traffic is just the ABS fault information. And if that's the only information that's being
[37:47.560 --> 37:54.360]  disclosed by these radiators on a remote read, then you're not really losing confidentiality
[37:55.120 --> 38:01.980]  much. Now if you are a fleet that's deploying other technologies like, you know, way axles
[38:02.620 --> 38:08.720]  or maybe even your door sensors, any canvassing technology in the trailer, this kind of stuff
[38:08.720 --> 38:15.060]  might be more confidential. You wouldn't want to have it disclosed. In terms of the impact
[38:15.060 --> 38:19.820]  in other technologies, other applications of the Intel on P485, we don't really know.
[38:20.040 --> 38:26.320]  Now one of the reasons we wanted to do this talk is that there are future impacts that really matter.
[38:26.320 --> 38:32.900]  The ATATMC is working on putting together a new next generation tractor-trailer interface,
[38:32.900 --> 38:40.180]  and one of the propositions include exchanging keys over PLC. Not that, you know, you can't
[38:40.180 --> 38:45.500]  do key exchange without guarantees of confidentiality, but we just want everyone
[38:45.500 --> 38:50.480]  designing those systems to be aware of the fact that you can't assume that what you exchange over
[38:50.480 --> 38:56.540]  these buses will be confidential. So it could be a problem if it's not implemented correctly.
[38:56.760 --> 39:01.740]  And then as we mentioned at the beginning of the presentation, this is not unique to PLC for trucks.
[39:01.740 --> 39:06.440]  This behavior is present in other powerline technologies, and we encourage you to look
[39:06.440 --> 39:11.120]  at the work of Baker and Martinovic, who showed that this happens in plug-in electric vehicle
[39:11.120 --> 39:18.180]  chargers. Now what can we do about it? Presently, there's not a whole lot you could do on existing
[39:18.180 --> 39:22.780]  trailers, because we think that really it's these long wires and the high voltage levels that are
[39:22.780 --> 39:30.100]  contributing to this. But for the future, there is something you could do. You also should, if you're
[39:30.240 --> 39:35.860]  a fleet, consider what kind of information is flowing on your trailers. If you are using airway,
[39:35.860 --> 39:41.280]  if you are using door sensors or canvassing systems, you might want to be aware that that
[39:41.280 --> 39:45.760]  kind of information can't be considered confidential when your trucks are rolling down the road.
[39:46.540 --> 39:51.600]  You also should be aware if your maintenance departments configure your trailer ECUs to do
[39:51.600 --> 39:56.300]  any streaming of readings, which is possible on several of the manufacturers, where you can
[39:56.300 --> 40:01.600]  configure them to continuously stream wheel speed readings or temperature or voltage readings. Those
[40:01.600 --> 40:07.040]  wouldn't be considered confidential anymore on those buses. But for the future, when they're
[40:07.040 --> 40:12.000]  designing the next tractor-trailer interface, I think the main mitigation that needs to be taken
[40:12.000 --> 40:19.040]  into place is reducing those emissions. And that should be able to be achieved by using PLC on
[40:19.040 --> 40:26.080]  power lines only between the connections where those J560 connectors are. We recognize that the
[40:26.080 --> 40:31.620]  J560 connector is not going anywhere. It's going to be too expensive to try to get fleets to move
[40:31.620 --> 40:38.600]  off of it. So if we only use PLC in between the J560 connectors, that should reduce the radiated
[40:38.600 --> 40:45.300]  emissions. If we only use it in between those J560 connectors, it also affords designers the
[40:45.300 --> 40:50.940]  opportunity to use lower transmit voltages because the signals don't have to reach
[40:51.800 --> 40:57.760]  across the entire tractor-trailer or multiple, especially multiple trailers in tandem.
[40:59.240 --> 41:06.260]  So this issue has, throughout the process, has been disclosed to various parties over the past
[41:06.260 --> 41:10.180]  eight months or so. We've been in contact with trailer equipment manufacturers, all three of the
[41:10.180 --> 41:16.400]  major ones. We have reached out to all the trailer builders. Only one of them responded to us.
[41:16.660 --> 41:22.960]  We have coordinated the disclosure with NMFDA members and our sponsors. We've also done it with
[41:22.960 --> 41:29.140]  what was previously ICS CERT, who now wants to be called the CISA Vulnerability Disclosure Program.
[41:29.600 --> 41:34.400]  And they themselves also reached out to the trailer builders that didn't respond to us.
[41:35.160 --> 41:45.760]  At this time, CISA BDP has assigned CVE-2020-14514, and there is a advisory on this issue of trailer
[41:45.760 --> 41:52.720]  powerline communications to raise awareness forthcoming. So in terms of future work, it's
[41:52.720 --> 41:58.220]  kind of got two different directions. I know our AIS friends here do a lot of industrial control
[41:58.220 --> 42:02.540]  systems work, and they're very interested in looking at applications of the same method to
[42:02.540 --> 42:07.140]  various other powerline communication technologies, some of them listed here.
[42:07.360 --> 42:13.020]  On the transportation side, very much would like to improve those truck tuck features,
[42:13.020 --> 42:19.940]  you know, get some PLC read going, maybe use the PWM unit instead. I recognize that those
[42:19.940 --> 42:24.460]  DC blocks could be implemented differently, maybe capacitive coupling on one side of the
[42:24.460 --> 42:30.160]  transformer instead of removing the transformer. Also, the new Balin-19s have really great screw
[42:30.160 --> 42:35.640]  terminals, so you could have a much more rugged connection to the powerline. We also would like
[42:35.640 --> 42:41.880]  to take Chris's receiver code and figure out just how far the reception can be done reasonably using
[42:41.880 --> 42:46.120]  one of these cheap active antennas, and maybe some of the other more fancy active antennas
[42:46.120 --> 42:51.560]  that we've bought since then. And then there's also looking at the other places where you find
[42:51.560 --> 42:57.540]  PLC. We're told that PLC is also used in intramodal, which is where people take containers
[42:57.540 --> 43:04.360]  and put those on top of flat cars or put them on top of trailers on the road as well. So we'd like
[43:04.360 --> 43:10.560]  to have a look at how PLC integrates in that space. And there's also this thing, which should
[43:10.560 --> 43:15.300]  be really fun to look at, that someone took a trailer brake controller and of course added
[43:15.300 --> 43:21.110]  Wi-Fi to it, because that's a great idea. If anyone wants to have fun with a trailer brake controller,
[43:21.930 --> 43:28.430]  check this one out. But also at the Car Hacking Village, we have two brake controllers
[43:28.430 --> 43:32.650]  hooked up to pressured air. I'll tell you about that a little more in a minute.
[43:33.370 --> 43:39.790]  So yeah, in summary, in conclusion, we got you two tools. There's PLC for TruckDuck,
[43:39.790 --> 43:46.070]  which enables you to write to PLC using 1-bit PLC chirps that we did with bit banging.
[43:46.070 --> 43:50.670]  You can make an arbitrary waveform, you know, you can have different PLC MIDs than you do for
[43:50.670 --> 43:57.090]  the J1708 payloads. Everything we put together is compatible with Haystack's PyHV Networks modules.
[43:57.470 --> 44:03.390]  There's also the ability to read PLC traffic remotely, and this is tracked also internally
[44:03.390 --> 44:13.410]  as ICSVU-227452, and I gave you the CVE earlier. And the GR-J2497 tool that Chris told you all
[44:13.410 --> 44:21.790]  about is capable of receiving this traffic at a distance of six feet. And also that GR-2497 tool
[44:21.790 --> 44:26.910]  is itself compatible with the PyHV Networks modules from Haystack. So this is what I was
[44:26.910 --> 44:32.690]  trying to tell you about. We actually have a couple trailer brake controllers turned upside down,
[44:32.690 --> 44:39.470]  and we've connected Nerf dart firing cactuses to the exhaust ports on the bottom, and we're
[44:39.470 --> 44:45.270]  running pressurized air on them so that if you can figure out how to do a valve test or do an
[44:45.270 --> 44:50.870]  ECU reset on one of these things, it should push air through that exhaust port and you should fire
[44:50.870 --> 44:56.230]  those Nerf darts. And they're connected up on the Virtual Car Hacking Builder system, so there's a
[44:56.230 --> 45:01.930]  Twitch stream and remote logins to the shells. We do hope that you log in and have a try, and maybe
[45:01.930 --> 45:08.970]  if you get familiar with them, have a try at that Wi-Fi trailer unit. I know I'd like to someday too.
[45:11.410 --> 45:16.930]  What we did here was, you know, not the result of just Chris and I's effort, but really the result
[45:16.930 --> 45:22.430]  of a lot of people committing a lot of resources and assistance over the past few months. And I
[45:22.430 --> 45:27.390]  really want to take an opportunity to put all their names up here and thank them. Really, this
[45:27.390 --> 45:33.550]  wouldn't be possible without, you know, support of a team and a community, and I feel really lucky to
[45:33.550 --> 45:40.150]  be a part of both. So thank you very much for your time. I'll be over in chat with Chris,
[45:40.150 --> 45:44.450]  hopefully answering any questions you have, and I'll see you at the Virtual Car Hacking Village
[45:44.450 --> 45:46.450]  later. Bye!
